As new generations of handsets, and other wireless communication devices become embedded with more applications and complexity, there is a need for ever more integration. The trend in mobile radio communications is towards complex multi-radio systems comprised of several parallel transceivers. This implies a leap in complexity of the radio frequency (RF) front-end (FE) design. The RF circuits of wireless communication devices are particularly difficult to integrate, due to the need for high power radio frequency circuits and components, which are inherently hardware rather than software or firmware based.
An RF Front-End Control Interface (hereinafter referred to as ‘RFFE’) specification is one of a number of specifications that has been developed by the mobile industry processor interface (MIPI™) Alliance, in order to offer a common and widespread approach to controlling RF components and circuits employed in front-end devices. There are a variety of RF front-end devices, including Power Amplifiers (PA), Low-Noise Amplifiers (LNA), filters, switches, power management modules, antenna tuners and sensors. These functions may be located either in separate devices or integrated into a single device, depending on the application. RF front-end devices are often developed in process technologies, where diverse technology choices are necessary to meet the functional and performance requirements of the application and the different front-end circuits. Often, in some process technologies used for RF front-end applications, the implementation of additional (controlling) digital logic is costly and technologically problematic. A typical solution to the control of many RF components and circuits is to implement a master (control) device and one or multiple slave devices that are controlled by, or responsive to, the master device. Consequently, simplicity has been a core driver in RFFE development. A major factor in a RFFE design is to offer options to reduce slave control complexity to a minimum (for example to target approximately 300 to 500 gates). Thus, the MIPI™ RFFE specification, has been designed and positioned at the low complexity end of all interfaces, and is optimized for Slave device implementation simplicity, without sacrificing a broad set of features.
Referring to FIG. 1, the known MIPI™ RFFE architecture is illustrated, whereby a master device 156 within a communication unit 100 is arranged to communicate with a plurality of slave devices 130 via a shared serial control bus, where multiple slaves are connected to the same bus in parallel. The MIPI™ RFFE supporting devices are interconnected by a system clock 132, system data 134 and a shared (between the multiple die) interface supply voltage (VIO) (not shown) on the shared serial control bus. Of particular note is that a full MIPI™ slave interface 152a, 152b, 152c is implemented on each slave device 158a, 158b, 158c. 
A MIPI™ RFFE master interface 110 of the master device 156 is in data communication with corresponding MIPI™ RFFE slave interfaces 152a, 152b, 152c of each slave device, namely first slave device 158a, second slave device 158b, and third slave device 158c, through a bus carrying system data 134. The processing of the data in each of the MIPI™ RFFE slave interfaces 152a, 152b, 152c of the slave devices 158a, 158b, 158c, is achieved using timing from the system clock 132. Each MIPI™ RFFE slave interface 152a, 152b, 152c includes a protocol circuit 120 that includes a protocol decoder 122 to decode the full MIPI™ protocol on a received data frame and an address decoder 124, for example with a device identifier that is used to determine whether data, commands, etc., on the shared data line 134 are intended for use by the particular slave device 158a, 158b, 158c. The protocol circuit further includes a full set of address registers 126 coupled to the address decoder 124.
Such an architecture is used as a traditional solution for a master device to control multiple slave devices on multiple die. As shown, each die comprises its own (i.e. duplicated) MIPI™ interface, each with a full protocol decoder to support a large number of slave features, including: MIPI™ RFFE state control, VIO controlled reset sequence, sequence start detect, slave identity decode, command decode, broadcast access, error handling. In addition, each die may be required to support a number of optional features, including: multiple word length access, bursts, read-back, programmable unique slave identifier (USID), triggered access. Thus, the known approach to decode everything on each die, coupled to an architecture that is required to distribute all of the data to all die, leads to more logic required in the die and too many communication/data lines between die. This known approach, therefore, increases the die size significantly, which results in increased cost.
In an architecture that implements MIPI™ RFFE, a further problem exists in that the die to support RF technology are typically more complex, and notably the die may use different processing technologies. For example, an architecture designer will not want large digital logic circuits on all die, as some die will inherently be specific to support RF technology, e.g. GaAs.
Therefore, known techniques for integrating MIPI™ RFFE modules that include multiple die would benefit from improved efficiency, reduced die size and reduced power consumption.